Event subscription and notification in network environments is becoming increasingly commonplace and important. Event subscription generally allows a first network entity to subscribe to event notifications from a second entity. Common examples of events include “presence” and “location;” however, the number and types of events are endless. For instance, conventional instant messaging services permit a first user to subscribe to a presence event for a second user. As such, during the period of the subscription, the first user receives updates as to the presence status (e.g., online or offline) of the second user. The subscription may be for a single inquiry, which will return a response of “present” or “not present” for the second user. The subscription may also be for a set period of time, which may result in multiple updates, or for other options (e.g., status change notifications, ongoing notifications, etc.)
Various protocols may be used for event subscription and notification. For example, the Session Initiation Protocol (SIP) may be used for such purposes (see, e.g., IETF request for comment document RFC 3261, entitled: SIP: Session Initiation Protocol, July 2002, the contents of which are hereby incorporated by reference in its entirety). SIP was generally developed to allow for initiating a session between two or more endpoints in the Internet by making these endpoints aware of the session semantics. Accordingly, devices (or users that run certain applications on these devices) are registered with the SIP backbone so that an invitation to a particular session can be correctly delivered to these endpoints. To achieve this, SIP provides a registration mechanism for devices and users, and it applies mechanisms such as location servers and registrars to route the session invitations appropriately. Although SIP is primarily a tool for initiating a communication session between endpoints, extensions to SIP have been proposed to provide event registration and trigger notification (see e.g., IETF document RFC 3265, SIP-Specific Event Notification, July 2002, the contents of which are hereby incorporated by reference in its entirety).
The SIP event framework, which would enable event-based information provisioning to any node in the Internet, is supposed to become a key element within the SIP infrastructure. Apart from providing information regarding certain events, such as presence or location, the SIP event framework provides the means for an event-based service invocation system. Currently, for example, messaging protocols such as SOAP (Simple Object Access Protocol) are being used to invoke Web services. The SOAP architecture provides a manner of encapsulating messages in envelopes, sometimes referred to as SOAP messages or SOAP envelopes, which can then be transferred from one network entity to another over a bearer protocol, such as HTTP (Hypertext Transfer Protocol). In this regard, information in the encapsulated messages can be formatted in any of a number of different manners, such as in accordance with Resource Description Framework (RDF) or XML (Extensible Markup Language). For more information on SOAP, see D. Box et al., Simple Object Access Protocol V1.1, W3C Note NOTE-soap-20000508, World Wide Web Consortium (2000), the contents of which are hereby incorporated by reference in its entirety.
A fundamental feature of such an event-based service invocation system is that full network connectivity exists for both requests and corresponding responses. Devices such as mobile stations, however, do not currently provide for such full network connectivity. In this regard, the adoption of service processing in mobile stations is constrained by the cellular operator network and its availability of public IP (Internet Protocol) addresses. Many mobile stations are not associated with a public IP address due to the limited number of addresses available in a number of current versions of IP, including IPv4. Due to the mobility of a device such as a mobile station, the mobile station may change its IP address throughout execution of a desired service. Since the necessary DNS (Domain Name Service) re-registration of the host URI (Uniform Resource Identifier) may require an unreasonable amount of time, possibly resulting in failure of connection requests from a server providing the desired service. Further exasperating the situation, the wireless data network has intrinsic QOS (Quality of Service) properties (e.g., shadows, handoffs, high latency) that present problems in a typical request-response SOAP environment.
Current cellular data networks typically only provide simple, synchronous web services initiated by mobile stations operating in such networks. In other terms, current cellular data networks do not enable devices to address and reach a mobile station using HTTP from the Internet to invoke a service at the mobile station. There exist or will soon exist a suite of mobile applications, however, that do not fit this simple programming model. In this regard, mobile stations are or will soon be capable of hosting reachable Web services themselves. Such services could encapsulate, for example, GPS location, personal calendar, contact information or the like.